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In the specification: 



Please replace the first full paragraph on page 9, bridging onto page 10, with the 
following paragraph: 

A description of tlie operation of the online payment system 100 will now be 
described with reference to Figures 1-2 and 5-6. At step 500 a registered merchant 
106 decides to place an item of digital content (article, music, picture, movie, other 
data) for sale utilizing the online payment system 100. The merchant 106 uses the 
encoder utility software 150 provided by the payment broker 1 18 to encrypt the digital 
content of the item for sale by first calculating a unique product key "Kprod" for the item 
(step 502). Kprod is derived by using the encoder utility software 150 to create a 
secure one way hash of data known to the merchant such as a product ID, the 
merchant secret key "Km", and a randomly generated number. Kprod is then used by 
the encoder utility software 150 to encrypt the digital content of the item using a 
known encryption algorithm (step 504). Once the item has been encoded, the 
encoder utility software 150 creates the file 180 to include a length identifier 200, a 
signed header 202, a product preview 204, and the digitally encoded content 206 
(step 506). The length 200 is used to identify the length of the header 202 portion of 
the file 180. The significance of this field is that it allows the plug-in 178 to know how 
much information needs to be read in order to display the header 202 while 
concurrently downloading the data for the product preview 204 and the encrypted 
digital content 206. Alternatively, the file length 200 can be used by the plug-in 178 
to only download the header 202 and present that information (required to complete 
the sale) on display 123. The remainder of file 180 (product preview 204 and 
encrypted digital content 206) are respectively downloaded only if the buyer chooses 
to view the product preview 206 or buy the digital content item. Accordingly, second 
and third file lengths can be included as part of the digital file 180 to respectively 
identify to the plug-in 178 the respective lengths of the product preview 204 and the 
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digital encrypted file 206. These file lengths allow the product preview data 204 to be 
downloaded and displayed upon request by the buyer without requiring the encrypted 
digital content file 206 to be downloaded until a buy decision is made by the buyer. 
Thus, using the file lengths to delay the downloading of various portions of file 180 
greatly improves network performance since selective portions of the file 180 are only 
downloaded upon command. 

Please replace the paragraph starting on page 14, bridging onto page 75, with the 
following paragraph: 

Subsequent to the download of the receipt and the product key by the by the 
buyer computer 122, the plug-in 178 via the browser 176 displays a post sales 
dialogue box on display 123 (step 800). The post sales dialogue box queries the 
user as to whether 1) they wish a refund, 2) they wish to take a survey (with an offer 
to be reimbursed for their time), and 3) the transaction is complete. If the buyer 
selects a request for refund, a new dialogue box appears prompting the user to 
select from among a predetermined number of reasons as to why they desire a 
refund or to enter their own reason (step 810). This information along with the receipt 
for the item is signed with the private key of the buyer Kbv and sent to the broker 
computer 132 (step 820). The broker computer 132 utilizes the buyer's public key 
Ksuto obtain the refund information and the receipt (step 822) and checks to ensure 
that 1) the buyer's account is active, 2) the refund request is for a previously 
purchased item and 3) a refund has not previously been made for that item (step 
824). Additionally, the broker computer 132 ensures that any preset period of time 
associated with how long after purchase a request for refund can be made has not 
been exceeded (step 824). If any of the above checks fail the buyer 102 is advised 
that a refund will not be given (step 826). On the other hand, if the checks are all 
positive, the broker computer 132 debits the refund amount from a dispute account 
associated with the buyer 102. That is, for each buyer, in addition to their vault 170 
there is a dispute account established at the broker computer 132. The dispute 
account has a threshold value associated with it that is debited each time a refund is 
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given to a buyer. Thus, for a given refund the dispute account and the merchant's 
account 162 for the merchant 106 selling the particular item are debited by the refund 
amount (step 828). The money debited from the merchants account is transferred to 
the buyer's vault 170 (step 830) and the buyer receives a message on display 123 
that the vault has been credited (step 832). However, if the dispute account is 
decremented to zero or a negative (step 829), a flag associated with the buyer's vault 
1 70 is set from an active status to an inactive status (step 834). At this point in time it 
is determined if the credit card accepts refunds (step 835), and if it does, any monies 
in the buyer's vault 170 are refunded to the buyer's default credit card (step 836). If 
the default credit card does not accept a refund, a message is sent to a general 
logging device so that a manual refund can be issued (step 838). The buyer 102 
then receives a message indicating that their vault is inactive and their remaining 
money will be credited to the default credit card or returned manually as the case 
may be (step 840). It is also possible to establish a time limit associated with the 
threshold value of the dispute account. That is, if the threshold value is not exceeded 
over a specified period of time, the dispute account is reset an initial value. 
Moreover, an additional counter can be added at the broker computer 132 for each 
buyer 102 that keeps track of the number of times a refund has been requested. If 
the number of requests exceeds a predetermined number, the buyer's vault is 
rendered inactive. Additionally, while the above described embodiment described 
the refund account as a descending register which starts at the threshold value and 
is debited down to zero, one skilled in the art will recognize that the refund account 
could be an ascending register which adds the refund amounts and inactivates the 
buyer's vault 170 when the predetermined threshold value is met. 



Please replace the second full paragraph on page 16, bridging onto page 17, with the 
following paragraph: 

In the above described embodiment, the encoded digital content 206 is placed 
on the web site 181 in encoded form (static encoding). A benefit of static encoding is 
that no software is required at the host web site 181. Thus, static encoding is good 
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for items that will have no content change such as previously written articles or 
musical recordings. However, if the item for sale is constantly changing data, such 
as stock information, the static encoding method is not efficient. In this situation, the 
encryption utility software 150 would be placed at the host web site 126 and the 
digital content to be purchased would be encrypted dynamically prior to each 
download of a file 180 to a buyer 102. Thus, for each buyer request for a digital 
content item a new product key Kprod is generated. This provides increased security 
since if Kprod is compromised for a single download of a file 180, only that specifically 
downloaded file 180 is compromised. In the static situation where there is a single 
Kprod associated with a file 1 80, if Kprod is compromised any download of the file 1 80 is 
potentially compronriised. The disadvantage of the dynamic encoding model as 
compared to static encoding is that it creates a greater burden on the host server 
126. The instant invention recognizes the advantages of static and dynamic 
encoding and in one embodiment contemplates a web site host 126 that has 
statically encoded digital content which is of a low value and a stable nature and also 
provides dynamic encoding of rapidly changing digital content and/or high value 
digital content items. Since the ultimate file structure 180 resulting from either the 
dynamic or static encoding is the same, the plug-in 178 can effectively perform its 
designed functions in either situation. 



Please replace the second full paragraph on page 19. 



An alternative method of providing the multiple copy/distribution corporate rate 
structure is to designate, in the buyer database 168, a designated rate for multiple 
copies (i.e. 50) that is automatically invoked any time the particular buyer 102 
purchases an item. In this situation the buyer 102 would be charged a cost 
associated with the initial cost of the item as well as the premium charged for the 
right to make/distribute the designated multiple copies. This feature also permits the 
customizing of discounts to individual corporations. 
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